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FOREWORD 


This report documents The Aerospace Corporation effort on 
Study 2.3, Systems Cost/ Performance Analysis, performed under NASA 
Contract NASW-2575 during Fiscal Year 1974. The effort was directed 
by Mr. B. H. Campbell. Mr. R. D. Kramer, Marshall Space Flight 
Center and Mr. R. R. Carley, NASA Headquarters were the NASA Study 
Directors for this study. Their efforts in providing technical direction 
throughout the duration of the study are greatly appreciated. 

This volume is one of three volumes of the final report for 
Study 2.3. The three volumes are: 


Volume I 
Volume II 
Appendix 
Volume III 


Executive Summary 

Systems Cost/ Performance Model 

Data Base 

Programmer's Manual and User's Guide 


Volume I summarizes me overall report. It includes the 
relationship of this study to other NASA efforts, significant results, study 
limitations, and suggested additional effort. 

Volume II provides a detailed description of the Systems Cost/ 
Performance Model. It also includes the model checkout and the results 
for three payload test cases. The Data Base is provided in the Appendix 
to Volume II. 

Volume III provides a detailed description of how the Systems 
Cost/ Performance Computer Program is organized and operates. The 
program listing, detailed flow charta and user restrictions are included. 
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1. INTRODUCTION 


As the space program matures into an applications industry, 
greater emphasis will be placed on improving the ability to predict the 
effect of program requirements on cost and schedules. Cost estimating 
techniques that give greater insight earlier in the program cycle are re- 
quired. As a step in this direction, this study was initiated to identify and 
quantify the interrelationships between and within the performance, safety, 
cost, and schedule parameters for unmanned, automated payload programs. 
These data would then be used in support of the over-all NASA effort to 
generate program models and methodology which would provide the needed 
insight into the effect of changes in specific functional requirements (per- 
formance and safety) on the total vehicle program (cost and schedule). 

Previous cost modeling approaches fall into one of two basic 
categories: "bottom-up" or "top-down". The "bottom-up" approach, which 
is tied to the development of a specific system, depends on detailed esti- 
mates of tasks, material costs, manpower requirements, and schedules. 
The total cost estimate is then obtained by summing the individual costs. 

"Top-down" models use CER (cost estimating relationship) 
approaches to estimate the cost of a specific system. Is terse models, the 
CERs are related to distinct parameters such as weigh* .ver, and point- 
ing accuracy. The deficiency of the CERs lies in the fact that, although 
they identify the cost drivers, they do not model why and how the costs 
are driven by the parameters. 

Since CERs have not been completely successful in meeting the 
prime criterion of determining sensitivity of cost to changes in program 
requirements, top-down approaches were judged unacceptable for a cost/ 
performance model. Hence, it was thought that a model oriented from the 
bottom-up could lead to fulfillment of this criterion. 
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2. OBJECTIVES 


The FY 1974 Study 2.3 had three objectives. The first objec- 
tive was to refine and improve the cost/performance methodology which 
was developed during the preceding fiscal year's study (see Ref. 2-1). The 
same two-step process of first establishing hardware designs and then 
estimating costs and schedules was retained. However, incomplete por- 
tions of the methodology such as the cost and schedule models were to be 
improved. 

The second objective was the application of the cost/ perform- 
ance methodology to the following vehicle subsystems: 

a. Stabilization and Control (SitC) 

b. Auxiliary Propulsion Subsystem (APS) 

c. Communications, Data Processing and Instrumentation 

(CDPI) 

d. Electrical Power Subsystem (EPS) 

1. Sources 

2. Conditioning and Distribution 

e. Thermal Control Subsystem (TCS) 

f . Structure 

The product of this effort is the Systems Cost/ Performance Model. 

The third objective was to implement the Systems Cost/ 
Performance Model as a digital computer program which would be capa- 
ble of operating on the MSFC Univac 1108 with only minor modifications 
necessitated by differences between the Aerospace CDC 7600 and the MSFC 
Univac 1108. The resulting program would be used by MSFC to perform 
initial program planning, cost/performance tradeoffs, and sensitivity 
analyses for mission model and advanced payload studies. 
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3. RELATIONSHIP TO OTHER NASA EFFORTS 


The FY 1974 Study 2. 3 makes extensive use of the FY 1973 
Study 2. 3, System Coat/Performance Analysis , results. The cost/ 
performance methodology developed during the preceding year's effort"' 
was improved and refined. The improved methodology was used to 
develop a model applicable to payload subsystems. 

The System Cost/Performance Model's data base formulation 
was based on the REDSTAR data base currently in use at MSFC. The 
REDSTAR system is the result of a 1972 fiscal year study {Ref, 3-1). 


4. APPROACH 


One of the first tasks in this study was to define the spacecraft 
generically by determining the functions performed by each spacecraft sub- 
system and the functions performed by specific hardware types within each 
subsystem. Obviously, interfaces between subsystems determined some 
of the functions to be performed. The outline of functions to be performed 
had to be complete in that potential subsystem designs, for the most part, 
are related directly to the functions they are required to perform. 

Block diagrams were developed for all generally uied subsystem 
configurations. The block diagrams consisted of the equipment types used 
in each configuration and illustrated the functions performed by the equip- 
ment. Since there may be an infinite number of block diagram variations, 
certain general block diagrams were established that were valid for most 
designs. 

A design algorithm was developed which performed the function 
of selecting preconfigured subsystem designs satisfying the input system 
or subsystem requirements. This implies that, as part of the vehicle 
design algorithm, a complete set of alternative designs has been established 
from which to choose. 

Given a specific design meeting the input requirements, the 
hardware required to implement such a design is selected from 
available off-the-shelf hardware which is contained in the data base. 
Obviously, the model must be capable of differentiating between hardware 
components of the same type and determining which hardware component 
has the characteristics to satisfy all of the requirements. 

In order to have a workable algorithm, the list of input data 
necessary to select a design and to size the necessary equipment has been 
established. The input data would normally include subsystem perform- 
ance requirements, interface requirements, and any other data necessary 
to make design decisions. 
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A data base consisting of ^formation on off-the-shelf hardware 
was established. The data content which is associated with each hardware 
component consists of four categories of information: 

a. Performance 

b. Safety (Reliability) 

c. Cost 

d. Schedule 

The four types of data contain sufficient information to allow the equipment 
selection algorithm to select specific pieces of equipment and to provide 
the necessary output data describing the design. The data were collected 
from in-house, Air Force, and NASA sources. Cost data were based on 
seven specific satellite programs. 

The Systems Cost/ Performance Model was implemented as a 
digital computer program. The program was written in the language of 
Fortran IV for the Aerospace GDC 7600 computer and adapted for the 
MSFC Univac 1108 computer. The program includes the Systems Cost/ 
Performance Model and the related data base. 

Two forms of model checkout were performed. The first was 
a set of computer runs to ensure that both the logic and arithmetic models 
were accurate and complete and that all submodels were interfacing prop- 
erly, The second set of computer runs was limited to a few special runs 
selected for the purpose of comparing the Systems Cost/ Performance 
Model against other existing models and against actual payload programs. 

• i 
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5. SYSTEMS COST /PERFORMANCE MODEL 


5. 1 GENERAL 

The general concept of the Systems Cost/Performance Model is 
illustrated in Figure 5-1. The user of the Cost/Performance Model must 
“pply certain program data which would normally include the payload per- 
formance requirements as well as general information necessary to select 
a payload design. The technical portion of the model consists of a two-step 
process: the first step is to select subsystem configurations which are 
acceptable to the user, and the second step is to select equipment from a 
data base to mechanize the* subsystem configuration. The reliability portion 
of the model adds redundancy to the design so that the reliability require- 
ments are met. The resulting output of the technical model is a number 
of payload designs which meet or exceed the input requirements. The 
acceptable designs are specified down to the subsystem component (assembly) 
level. The cost and schedule required to design, build, and operate each 
payload are estimated by summing up the individual cost and schedule allo- 
cations based on each end item assembly specified as part of the particular 
design. 

The technical portion of the Systems Cost/Performance Model 
is depicted in Figure 5-2. The expanded detail summarizes the inputs 
required by each subsystem. Most importantly, the interaction between 
subsystems as a design problem is illustrated. In order to design the 
Stabilization and Control (SStC) Subsystem, the vehicle weight, dimensions, 
and moments of inertia must be known. Design of the Auxiliary Propulsion 
Subsystem (APS) requires knowledge of the total impulse and thrust levels 
from S£cC. Design of the Data Processing Subsystem requires knowl- 
edge of the telemetry and data processing requirements for each piece 
of equipment in the vehicle. Design of the Communication Subsystem 
requires knowledge of the command and communication requirements 
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Figure 5-2. Vehicle Design/Equiprrent Selection 






for the entire vehicle. One must know the power requirements to design 
the Electrical Power (EP) Subsystem. Determining the structural makeup 
of the vehicle and the weight, dimensions, and inertias requires some in~ 
sight into what is contained within the vehicle and what the environment is. 
The reliability requirements impact the design of every subsystem through 
the addition of redundancy. The principal point to be made here is that by 
modeling the interaction of the subsystem design processes, the Systems 
Cost/Performance Model is not only a subsystem design tool, but is also 
a system design tool. 

5. 2 SUBSYSTEM MODELS 

5. 2. 1 Subsystem Configurations 

A subsystem configuration is a general design type which is 
developed mechanically by selecting appropriate equipment listed in 
the data base. The subsystem configurations (types) incorporated in the 
Systems Cost/ Performance Model are as follows: 

a. Stabilization and Control 

1. Dual spin 

2. Yaw spin 

3. Three-axis mass expulsion 

4. Mass expulsion with control moment gyros 

5. Mass expulsion with pitch momentum wheel 

b. Auxiliary Propulsion 

1. Cold gas 

2. Monopropellant 

3. Bipropellant 

c. Electrical Power Source 

1. Body-mounted solar arrays 

2. Oriented solar array paddles 


d. Electrical Power Conditioning 

1. Shunt regulation 

2. Shunt and discharge regulation 

3. Series load regulation 

e. Communications 

1. Separate uplink and downlink 

2. Unified link, common antenna 

3. Unified link, separate antennas 

4. Unified link, common antenna, plus separate downlink 

5. Unified link, separate antennas, plus separate downlink 

f. Data Processing 

1. General purpose processor 

2, Special purpose processors 

: g. Thermal Control 

(Dependent upon other subsystems and component requirements) 

h. Vehicle Shapes 

1. Cylinder 

2. Box 

3. Sphere 

i. Structure 

1. Semi-monocoque 

j. Redundancy 

1. Single system 

2. Dual system 

5.2.2 Equipment Description 

The model selects equipment for a specific design in one of 
three ways: 

a. Most equipment is selected from the data base on the basis of 
technical performance. 
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b. Some equipment which cannot be differentiated on the basis of 
technical performance is called up from the data base on a 
first-called basis in order to provide a complete design descrip- 
tion. * 

c. Certain equipment is not amenable to being cataloged in the data 
bass. This equipment is identified and specific parameters are 
determined. Examples include the wiring harness and the 
Thermal Control Subsystem components. 

An example of an equipment description in the data base is pro- 
vided in Table 5-1. 

5.2.3 Design Algorithms 

The design algorithms for all subsystems are summarised as 

follows: 


a. Stabilization and Control Subsystem 

1. Selects attitude measurement equipment 

2. Selects momentum exchange equipment 

3. Computes attitude control thrust level 

4. Computes total impulse required 

b. Auxiliary Propulsion Subsystem 

1. Selects thruster equipment 

2. Selects propellant equipment 

3. Selects pressurant equipment 

c. Data Processing Subsystem 

1. Selects computer or one digital telemetry unit per 
communication downlink 

2. Selects command distribution equipment 

d. Communication Subsystem 

1. Selects communication equipment 

e. Electrical Power Subsystem 

1. Sizes solar array 

2. Selects batteries and voltage regulation equipment 

3. Selects power conditioning equipment based on require- 
ments of all other selected equipment 

*It is proposed that this category be eliminated in future models by 
differentiation of all equipment as suggested in paragraph a. 


f. Thermal Control Subsystem 

1. Sizes thermal mass, insulation, heaters, radiators, 
louvers, and heat pipes 

g. Vehicle Sizing 

1. Estimates structural weight 

2. Estimates thermal control weight 

3. Estimates mechanism, booms, ana electrical harness 
weight 

4. Sums total vehicle weight 

5. Estimates payload adapter weight 

6. Estimates vehicle dimensions 

7. Estimates moments of inertia 

h. Structural Subsystem 

1. Determines actual wall thickness based on optimum 
weight design 

2. Determines stringer size and spacing 

3. Determines frame size and spacing 

4. Sizes end covers and center plate (if applicable) 

5. Sizes mission bay and solar array extensions 

The user must specify the following inputs: 

a. Vehicle orientation 

b. Orbit description 

c. Mission lifetime 

d. Attitude control requirements 

e. Powered flight thrust level 

f. SGLS or USB compatibility requirement 

g. Range and range rate requirement 

h. Structural material description 

i. Launch loads environment 

j. Maximum diameter, length and weight 

k. Mission equipment description 
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Table 5-1. Data Bate Example 


Subsystem: Auxiliary Propulsion (0808) 

Configurations: Monopropellant 

Equipment Type: Thruster (TRW 404620) 

Performance 


Technical Characteristics 


(1) Thrust level (N) 

18 

(2) Pulse life (cycles) 

93, 000 

(3) Inlet pressure (N/m^) 

4. 14 x 10 6 

(4) Total impulse (N-sec) 

6.49 x 10 4 

(5) ISP (sen) 

230 

(6) 


(7) 


(8) 


(9) 


(10) 


Power 


Average Power (watts): 

(near zero) 

Maximum Power (watts): 

5.5 

Minimum Power (watts): 

0.0 

Nominal Voltage (volts): 

28.0 

Maximum Voltage (volts): 

32.6 

Minimum Voltage (volts): 

26.0 

Converter /Inverter Requirement (flag): 

N. A. 

Weight (Kg): 

0.3 

Volume (cc): 

1700 

Vibration 


Randon (g, rms): 

19.5 

Non- Random (g): 

10.5 

Temperature 


Maximum (deg K): 

322 

Minimum (deg K): 

278 

Pressure (N/m^) 

(Unknown) 
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Table 5-1. Data Base Example (Continued) 


Performance (continued) 

CDPI 

Power Switching Commands (No.): 
Time Tagged Commands (No.): 

Other Commands (No.): 

High Rate Telemetry 

Number of Analog Points (No.): 
Number of Digital Points (No.): 
Sample Rate (sec'l): 

Word Length (bits): 

Low Rate Telemetry 

Number of Analog Points (No.): 
Number of Digital Points (No.): 
Sample Rate (sec‘*) 

Word Length (bits): 

Safety 

Failure Model (flag): 

Failure Parameters 

Failure Rate or Mean (x 10 V hr): 
Standard Deviation (x 10+9 hr): 
Dormancy Factor (N.D.):* 

Total Number of Redundant Elements (No.): 

Cost 

Design Engineering ($1000): 

Test and Evaluation ($ 1000): 

Unit Production ($ 1000): 

Reference Quantity (No.): 

Factor (N. D. ) : 

Schedule 

Development Lead Time Constant (months): 
Development Lead Time Variable (months): 
Qualification Lead Time Constant (months): 
Qualification Lead Time Variable (months): 
State-of-Art Factor (N.D. ): 

*Non -dimensional 


0 

0 

0 

0 

0 

0 

0 

2 

0 

1 

8 


5 

1700 

N. A. 

O . 1 

12 


127 

150 

9 

4 

1 


3.0 

1.0 
1.5 
0 . 1 
1.0 
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5 . 3 


RELIABILITY MODEL 


As a result of satisfying the input performance requirements, 
a finite number of designs are established by the Cost/Performance Model. 
The next step in processing these designs requires the use of the reliability 
equations. These equations are categorized as to reliability assessment, 
failure detection probability, and false alarm probability. 

The first of these equations, the reliability assessment, is used 
to calculate the reliability of each configuration. This is done at the ele- 
ment level, i. e,, each identifiable subsystem component. Failure rate 
information stored in the equipment data base for each component is ex- 
tracted as needed by the model. The failure rates are then combined by 
the reliability equations to calculate total reliability for a given mission 
duration. The calculated reliability of each particular design is evaluated 
against the specified level provided as the model input. However, the 
design is not discarded if it does not meet the specified reliability level; in- 
stead, a search for the least reliable element is initiated. The criterion 
for least reliable is that element which, if made redundant, results in the 
largest increase in reliability or in mean mission duration per unit weight 
or cost increase. Upon identification, the least reliable element is paral- 
leled by a n identical unit and the system reliability is recalculated. The 
evaluation and paralleling process continue until the redundancy exceeds a 
specified limit. If the system still does not meet the specified reliability, 
the system is deleted from consideration as a viable single-string system. 
However, if it does meet or surpass the required reliability level, the 
system failure detection and false alarm probabilities are also calculated. 
The process described above continues until each design stored as a result 
of meeting performance requirements has been processed. 

The procedure described above constitutes one-half of the total 
Reliability Model. Following completion of the basic scheme, the whole 
procedure is repeated with each design mechanized as an active/ standby 
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(dual string) system. The term active/ standby refers here to a completely 
separate system in addition to modular levels of redundancy. 

The required input data includes: 

a. Mission life 

b. System reliability 

c. Basis for selecting redundancy 

The output information supplied by the Reliability Model includes the 
redundancy required for each component and the amount of expendables 
(propellant) required. 

5. 4 COST MODEL 

The Cost Model consists of cost equations which process cost 
information associated with each subsystem component. The required 
input data includes the number of qualification vehicles and flight vehicles. 

The Cost Model adds up the cost information for the following 
categories for every piece of equipment (up to 39 types) selected from 
the data base; 


a. Design engineering 

b. Test and evaluation 

c. Production engineering 

d. Unit production 


Cost Estimating Relationships (CERs) are used to estimate the 
costs for components which are not amenable to cataloging, including: 


a. Structure 

b. Thermal control 

c. Wiring 

d. Power conditioning equipment 

e. Solar arrays 

f. Propellant tanks 


The nonrecurring coBt for each component takes into account 
design, development, the effects of redundancy, and yearly price changes. 
The average recurring cost for each equipment component is adjusted to 
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account for labor, materials, and yearly price changes. If more than one 
unit is to be built, a learning curve is used to account for reduced unit 
cost as additional quantities are built. Remaining system cost categories 
including: 

a. Tooling and test equipment 

b. Quality control 

c. System engineering and integration, and 

d. Program management A 

are estimated on the basis of predetermined percentages of the total of 
each of the four basic component cost categories. 

The total nonrecurring cost is the sum of the nonrecurring costs 
for all of the system components. The total recurring cost is the sum of 
the products of the equipment quantities and the appropriate average re- 
curring costs. The total spacecraft cost is obtained by summing the total 
recurring and nonrecurring costs and then adding in the mission equipment 
cost and contractor's profit. 

5.5 SCHEDULE MODEL 

Schedule equations are used to estimate the amount of time re- 
quired to develop an operational system. In general, the estimates of the 
schedule lead times are functions of the hardware selected by the Cost/ 
Performance Model. The justification fo. iuch an approach lies in the 
fact that specific equipment components provide an indication of the com- 
plexity of the system and, hence, a measure of the time required to com- 
plete the activities associated with the system. 

The model performs the following operations: 

a. Computes the development and qualification lead times for 
each component. 

b. Computes the development and qualification lead times for 
each subsystem. 

c. Computes the system lead time. 

d. Determines the critical path. 

e. Computes the total program duration. 

The Schedule Model output includes the various lead times, the total pro- 
gram duration, and the critical path. 


5. 6 


COMPUTER PROGRAM 


The Systems Cost/ Performance Model has been implemented 
as a digital computer program. The program is written in the language of 
Fortran IV, as adapted to The Aerospace Corporation's CDC 7600 computer 
and MSFC's Univac 1108 computer. The program includes the Cost/ Per- 
formance Model and the related data base. 

The Systems Cost/ Performance Computer Program incorp- 
orates four technique* to make the program as efficient as possible while 
retaining maximum versatility. The first technique is to pre-sort the 
equipment data base according to attributes specified by the program user. 
This technique is desirable in order to allow the program to select equip- 
ment from the data base on the basis of the first piece identified which 
satisfies the requirements. 

The second technique consists of having the program always 
do a "macro" search of combinations of major subsystem configurations. 

As an example, one combination of major subsystem configurations would 
be a three-axis stabilized payload using cold gas propellant, oriented 
solar array paddles, shunt power regulation, and so forth. The subsystem 
configurations have been specified in Paragraph 5. 2. 1. 

The third technique is to mechanize the digital program to 
have the capability to try all combinations (micro-search) of equipment in 
any single subsystem, if requested by the user. The user must specify the 
configuration types for each of the other subsystems to exercise this option. 
The program will select, design, and print out all acceptable combinations 
of equipment for the specified subsystem. This technique or option allows 
the subsystem specialist to perform detailed trade studies. 

Because the program may identify a large number of design 
combinations which satisfy the input requirements, a post-sort routine 
(the fourth technique) is included which sorts the acceptable designs accord- 
ing to attributes as specified by the user.* This technique provides the 
computer program user with the designs listed in an organized fashion. 

♦ The post-sort routine is not currently in the computer program, but 
can be added very easily. 
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Hence, the process of finding the "best" design out of all of the possible 
contenders is performed by the program. 

The general sequence followed by the computer program is 
to read the input requirements, make one pass through the subsystem de- 
sign algorithms, determine the required redundancy, and then make a 
second pass through the subsystem design algorithms with the data obtained 
from the first pass. Redundancy is not altered on the second pass prim- 
arily because the Reliability Model is extremely time-consuming. Cost and 
schedule are estimated for each acceptable design. * 

5.7 SIGNIFICANT RESULTS 

The major accomplishment of the FY 1974 effort was the 
development of a model possessing the ability to design unmanned, auto- 
mated payloads. Subsystem, safety, cost, and schedule models were 
developed. Each of these models interfaces properly with the remainder 
of the model. The model is self-sufficient in that no intermediate steps 
need be performed by the user. The Systems Cost/ Performance Model has 
been implemented as a digital computer program and is operational on The 
Aerospace Corporation's CDC 7600 and IBM 370-155 computers. 

Three test cases were used to check the Cost/Performance 
Model and the operation of the computer program. The three test cases were: 

a. Defense Satellite Communication System (DSCS-II) 

b. Earth Resources Technology Satellite (ERTS-A) 

c. Orbiting Solar Observatory (OSO-I) 

The test results were reviewed at the system, subsystem and assembly 
levels. Table 5-2 compares the actual subsystem weights for DSCS-II 
with weights for the design generated by the Model. 

The results of these three test cases indicate that the cur- 
rent Model is capable of estimating spacecraft program costs with reasona- 
ble accuracy. The error in the total cost estimate (using preliminary CERs) 
is less than 23% relative to the actual DSCS-II costs. Table 5-3 compares 

*The six CERs in the Cost portion of the computer program are prelimi- 
nary versions and will be updated to correspond to the documented CERs 
under a follow-on contract, 

**The Cost/Performance Model is expected to be operational on MSFC's 
Univac 1108 computer in the near future. 


Table 5-2. DSCS-II Weight Estimate Comparison 


Weight (kg) 


Subsystem 

Estimated 
by Model 

Actual 

Weight 

Difference 

(%) 

Structures 

148. 7 

129. 7 

+ 3.4 

Thermal Control 

7.C 

17.6 

-1.9 

Communication, Data Processing and 
Instrumental .a 

29.3 

58. 7 

-5.2 

Electrical Power (incL Distribution) 

186.8 

147.8 

+6.9 

Stabilization and Control 

73.0 

5d.2 

+ 3. 1 

Auxiliary Propulsion 

50.0 

13. 7 

+ 6. 4 

Expendables 

50. 8 

55.2 

• 0. 8 

Mission Equipment 

82. 1 

82. 1 

- 

Total Payload 

o27. 7 

560.0 

+ 11.9 

Adapter 

7. 7 

6. 7 

+ 0. 2 

Launch Weight 

635.4 

566. 7 

+ 12. 1 


Table 5-3. 

DSCS-II Cost Estimate Comparison 


Model Estimates 
($1000) 

Subsystem CERs* 
($1000) 

DDT&E 

(61. 370) 

(61, 610) 

Spacecraft 

29, 070 

29. 310 

Mission Equipment 

32. 300 

32, 300 

Investment 

(63. 151) 

(49, 610) 

Spacecraft 

43, 111 

29, 570 

Mission Equipment 

20. 040 

20. 040 

Operations 

(2. 573) 

(4. 540) 

Contractor Fee 

(5, 053) 

(4. 439) 

Total 

(132. 147) 

(120, 199) 


*The subsystem level cost estimates were generated by the current payload 
cost estimating model, PALCM. 
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r- 


the cost estimates for DSCS-II generated by the Model with the equivalent 
cost estimates generated by subsystem CERs. For these program checkout 
cases, the model results are consistent with conventional cost-versus- 
weight CERs. 

At the same time, the model provided insight into the effect 
of other variables (e. g. , reliability) on payload cost Figure 5-3 presents 
the cost estimates generated by the Model as a function of payload relia- 
bility. The cost estimates are relatively insensitive to change in payload 
reliability at low levels due to the inherent reliability of a single string 
system. However, attempts to increase reliability substantially cause costs 
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Figure 5-3. DSCS-II Cost versus Extended Life 
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to turn upward, reflecting the diminiahing returns and increasing coats of 
adding redundancy. The cost curves generated by the Model provide more 
accuracy than the current C£R approaches which are restricted to 
straight-line approximations about the nominal values. 

Generally speaking, the Cost/Performance Model should 
exceed the performance of "top-down" models. The Model uses a "bottom- 
up" approach and, therefore, designs the payload at the assembly level. 
Greater accuracy is achieved by the very nature of the more detailed design. 
This accuracy will be reflected in the cost and schedule model estimates. 

A second attribute of the Cost/Performance Model is the completeness of 
the design specified. Pieces of equipment are not forgotten and redundancy 
is automatically included in the specified design. In addition, the impact of 
all subsystem interfaces and intera. vions is properly modeled. The net 
result is a payload design which is as accurate and complete as one from a 
Pre-Phase A study and which is available to the Cost/ Pe rformance Computer 
Program user immediately. 

Because of the detailed nature of the Model, the potential uses 
of the System Cost/ Performance Model exceed those for "top-down" models. 
The following uses of the model are suggested; 

a. Establish specific payload designs and the related costs and 
schedule to meet th*. program requirements. 

b. Determine the sensitivity of the design and its costs and 
schedules to changes in requirements. 

c. Perform trade studies to identify optimal designs. 

d. Develop standardized designs using a data base consisting 
of standardized equipment. 

e. Identify low cost designs using a data base consisting of 
off-the-shelf equipment. 

f. Use current Model to establish mathematical relationships 
within and Detween performance, safety, cost, and schedule 
without the use of a discrete data base. 

g. Perform modularity studies by modifying the Model to assign 
equipment to modules. 

The Model can readily be expanded in capability to perform many other 
studies as well. 
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The computer program aids the designer in performing trade 
studies and simplifies the achievement of a balanced system design. If 
fully developed, the Model can become a versatile tool in terms of prelim- 
inary program planning and in actual program management. 
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6. STUDY LIMITATIONS 


This year's modeling activity was limited to unmanned, auto- 
mated payloads. There was no attempt to incorporate the effect or influ- 
ence of the Shuttle system on the design of payloads. 

Funding limitations prevented application of the Systems Cost/ 
Performance methodology to mission equipment and to ground support 
equipment and operations. The Schedule model was deemphasieed for the 
same reason. 

The focus of the current study was on developing a model 
rather than on augmenting a data base. Only after the model was success- 
fully developed and proven as a useful tool could data collection be justi- 
fied at such a detailed level. Most importantly, the current Model is 
limited in the range of payload designs it can generate by the limited num- 
ber of equipment in the data base. Accuracy of the cost estimates is limi- 
ted by the relatively limited amount of cost data which could be reduced 
and processed to support the data base cost entries. 


7. SUGGESTED RESEARCH AND ADDITIONAL EFFORT 


It is recommended that the Model be thoroughly verified and 
validated. The most useful validation procedure would be to use the Model 
on test cases selected from historical programs, operational programs, 
and new starts. Historical and current programs provide the most accur- 
ate data with which to validate the Model. New start programs will test 
the applicability of the Model as a preliminary planning tool. 

The focus of the current study was on developing a model 
rather than augmenting a data base. On the other hand, lack of adequate 
data hindered the development of the FY 1974 model. The Cost Model must 
be considered preliminary and the Schedule Model cannot be considered 
operational until sufficient data has been collected to improve and validate 
the model. Hence, successful use of the Systems Coat/Performance Model 
depends entirely on the collection of performance, safety, cost, and sched- 
ule data at the subsystem component (assembly) level. 

Although the Model is operational, there are a number of 
improvements which should be implemented. The suggested improve- 
ments in the subsystem, reliability, cost, and schedule models are listed 
below: 

a. Subsystem Models 

1. Stabilization and Control 



(a) 

Incorporate a magnetic torquer in the model. 

2. 

Data 

Processing 


(a) 

Incorporate data compression in General Purpose 
Processors. 


(b) 

Incorporate a tape recorder in the model. 


(c) 

Incorporate an algorithm for selecting Command 
Distribution Units. 

3. 

C nmmunic ation s 


(a) > 

Expand the model from the Air Force's Space 
Ground Link System (SGLS) to include NASA's 


Unified S-Band (USB), S-Band and VHF equipment. 


b. 


d. 


4 . 


(b) Expand the model to apply to interplanetary 
missions. 

Structures 


(a) Incorporate a truss structural configuration. 
Reliability Model 

1. Incorporate mission equipment in the model with pro- 
vision for increasing redundancy of the mission equip- 
ment. 

2. Incorporate a model of pulse -operation (short duration) 
modules. 

Cost Model , 

1. Improve the accuracy and applicability of the data base 
and CERs by collecting and processing additional data. 

2. Develop CERs for equipment not previously flown. 

3. Model the relationship between cost and schedule. 
Schedule Model 

0 

1. Improve the approach and accuracy of the model by 
collecting and processing additional schedule data. 

In general, it is recommended that the fiscal year 1975 effort 
include extension of the model to other space vehicle systems; improve- 
ment of the data base to be acceptable for performance, safety, cost, and 
schedule analyses; testing of the capability of the model to predict space 
vehicle interrelationships; and a user review to evaluate the potential of 
the model to assist in programmatic change control such as configuration 
management. 
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